Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/cat/cat-minutes-92jul.txt

Text File | 1993-02-17 | 7.8 KB | 177 lines

Editor's Note:  Minutes received 7/28

CURRENT_MEETING_REPORT_


Reported by John Linn/DEC

Minutes of the Common Authentication Technology Working Group (CAT)

Recorded by John Linn and incorporating information from summary slides
submitted by P. Rajaram.

The CAT Working Group met for one session at the July 1992 IETF. Primary
discussion topics were:


   o Document status review.
   o Liaison requests from other standards organizations.
   o Technical discussion of mechanism negotiation.


Document Status Review

The request to advance the base GSS-API Internet Draft to Proposed
Standard was the first such request to be processed after the adoption
of a security area policy requiring that specifications be submitted to
independent reviewers before passing them on to the IESG. This
pre-review process is currently in progress, with one set of comments so
far received and forwarded to the CAT mailing list.  Steve Crocker
indicated that the pre-review will be complete by August 10th.

Some changes to the GSS-API C Bindings Internet Draft will be required,
in response to accumulated comments and to track updates to the base
specification.  Cliff Neuman indicated that he expects to produce an
updated version of the Kerberos V5 Internet Draft by the end of July.

Liaison Requests from other Standards Organizations

Subsequent to the San Diego IETF, John Linn had been approached by
representatives from the X/Open Security Working Group and the POSIX
Distributed Security Study Group, both of which indicated interest in
adopting GSS-API within their standards processes.  A short hardcopy
paper, ``Distributed Security Services Programme'', was received from
the X/Open group; copies were distributed at the meeting.

X/Open engages in activities including definition and implementation of
interface test suites, and in establishment of agreements with end
system vendors to encourage availability of adopted interfaces on a wide
variety of platforms.  These activities appear usefully complementary to
IETF-CAT goals.  In terms of process, Vint Cerf underscored the position
that it was wholly appropriate for X/Open or other bodies to incorporate
IETF specifications into their processes through reference to
standards-track RFCs, but that change control to the specifications must
remain within the IETF.

                                   1





Piers McMahon attended the CAT session and has been a participant in the
POSIX Distributed Security Study Group.  He indicated his perception
that POSIX would prefer to adopt GSS-API by way of X/Open rather than
initiating a separate POSIX activity in this area.  It was noted that
authorization-oriented GSS-API extensions are under consideration in
several forums, and that X/Open might also be a likely forum for
standardization of such extensions.

John Linn accepted the action to coordinate with X/Open representatives
to evolve a scope and action plan for liaison activities, and to report
results back to the CAT Working Group.  Piers plans to send a note
reporting on relevant status of the POSIX study group, which was meeting
in Chicago simultaneously with the Cambridge IETF.

Technical Discussion of Mechanism Negotiation

P. Rajaram indicated that he had been investigating approaches on
mechanism selection and negotiation within the GSS-API framework, and
led a discussion on the topic.  He observed that GSS-API mechanism types
correspond to groupings of authentication protocol per se, associated
encryption algorithm, and associated hash function, and expressed a
belief that three or four basic authentication protocols would likely
exist in the marketplace but with many algorithm combinations.  Further,
different protocol/algorithm combinations would vary in their support
for per-message confidentiality and integrity features and in their
performance characteristics.  It was observed, however, that divergent
feature support within a single mechanism could result in cases where a
given GSS-API implementation might not be able to determine the feature
set supported by a desired peer.  (Editor's Note:  I believe that this
could be reconciled by design of a mechanism in which peers declared
their supported features to one another in exchanged tokens, without
returning an indication of the features jointly supported until the
context establishment sequence is complete.)

Raj suggested that the selection of appropriate mechanisms, and of
feature sets within those mechanisms, should be refined based on
application-stated requirements (e.g., integrity and confidentiality
support, in addition to the service indicators already incorporated) and
domain-administered policies (e.g., based on application and user names,
initiator and target addresses, connection paths, time of day, ...).  It
was further suggested that GSS_Init_sec_context() be extended to allow
an application to indicate a set of mechanism types as input to
negotiation, rather than only a single type or a ``default'' specifier,
and that a new Map_mechanisms() call accept a mechanism set and an
indicator of application service requirements and return a subset of the
input mechanism set suitable to satisfy the indicated requirements.
Mechanism selection would be performed on an end-to-end basis, between
peer applications, based on an intersection of the sets acceptable to
both peers.  This proposal led to an active discussion about the danger
that use of negotiation to arbitrate among multiple mechanisms would
generally result in the use of the weakest (``low water'') alternative.
It was suggested that each end system would appropriately maintain a
database identifying (individually or through wildcards) the correct

                                   2





mechanism to use with particular peers.  It was further suggested that
target systems should be able to write ACLs selectively granting access
based on the mechanism with which an initiator was authenticated.

Given the level of controversy about the mechanism negotiation concept,
no specification changes to aid its support were immediately adopted.
Raj accepted an action to write a strawman proposal for a rendezvous
scheme which would arbitrate mechanism selection in a secure fashion,
and to distribute the result for mailing list discussion.  Interface
impacts would be revisited in the course of evaluating and evolving this
proposal.

Attendees

Derek Atkins             [e-mail]
Tony Ballardie           [e-mail]
Mark Baushke             [e-mail]
Mark Bokhan              [e-mail]
Geetha Brown             [e-mail]
Vinton Cerf              [e-mail]
Stephen Crocker          [e-mail]
Michael DeAddio          [e-mail]
Pierre Dupont
Tom Farinelli            [e-mail]
Barbara Fraser           [e-mail]
Shari Galitzer           [e-mail]
Gary Gaudet              [e-mail]
Kenneth Grant            [e-mail]
Theodore Greene
Neil Haller              [e-mail]
Mark Hollinger           [e-mail]
William Huyck
David Katinsky           [e-mail]
Stephen Kent             [e-mail]
John Linn                [e-mail]
Ellen McDermott          [e-mail]
P.V. McMahon             [e-mail]
Marjo Mercado            [e-mail]
Clifford Neuman          [e-mail]
Rakesh Patel             [e-mail]
Lars Poulsen             [e-mail]
Allan Rubens             [e-mail]
Jeffrey Schiller         [e-mail]
Martin Schulman          [e-mail]
Vincent Sgro             [e-mail]
Robert Shirey            [e-mail]
Jeremy Siegel            [e-mail]
Sam Sjogren              [e-mail]
Theodore Ts'o            [e-mail]
John Vollbrecht          [e-mail]
David Wang               [e-mail]
Peter Williams           [e-mail]


                                   3